1. Technical Field
This disclosure concerns generating test cases from graphical user interface applications (GAPs) to perform reference testing on web services. In particular, this disclosure relates to an efficient and non-invasive approach to generating reference tests cases and production data from GAPs for web services.
2. Background Information
Organizations spend a substantial portion of their software development project budgets to create test cases. A strong demand exists for systems that generate accurate test cases, efficiently and economically. However, many software development projects employ laborious and inefficient methods and systems, only to produce inaccurate and incomplete test cases that, as a consequence, fail to meet some or all of the testing requirements. A test case may include test data (e.g., valid input data) and a test oracle (e.g., an expected or valid output). Organizations face many of the same technical issues generating both test data and production data from reference applications, and develop elaborate data conversion programs to create production data for new applications. Software developers and system integrators (“developers”) commonly consider test data disposable and only used in testing. Accordingly, test data content may in fact be production data, though distinguished by name due to its role in the testing process.
Developers test new applications to validate that the software complies with system requirements. The testing process includes developing test logic based on detailed specifications, and alternatively, performing reference testing (i.e., a form of regression testing). Developers retest (i.e., regression test) modified software to ensure that a modification to the modified software operates properly, and that the modification has not caused other previously working functions of the modified software to fail. Reference testing includes comparing outputs from new applications against previously recorded (i.e., expected) outputs from the same application or another application. Test oracles may require developers to provide detailed and comprehensive descriptions of the desired behaviour for the new application. Consequently, the quality of a test oracle depends on the quality of the specification. Reference testing includes testing new applications (“target applications”) using information from legacy applications (“reference applications”). When developers migrate or model functionality from a reference application to a target application, developers attempt to reuse test data and test cases from the reference application. The purpose of migrating functionality includes replacing the reference application with the target application. In contrast, the purpose of modelling functionality of a reference application may include merely replicating the functionality of the reference application in the target application, and not for the purpose of replacing the reference application.
It is very commonly the case that after a software project team deploys a reference application into production for an organization, neither the organization nor the team preserves test data or testing documentation. Even though organizations may store data accumulated by reference applications over many years of use in production, organizations find it difficult to extract and develop test data and test cases from the reference applications to test target applications. Organizations that desire to use data from reference applications spend significant time and money in attempts to understand the source code and the data structures of the reference applications.
Modern systems often incorporate Graphical User Interface (GUI) Applications (GAPs) implemented in a closed and monolithic manner. Developers building target applications find extracting test cases from existing GAPs (reference applications) a difficult technical challenge, especially for closed and monolithic GAPs. Thus, a fundamental technical problem of interoperability for developers is how to extract test cases from existing GAPs, efficiently and non-invasively.
Developers and organizations purchasing system integration and software development services recognize the difficulty and enormous expense of developing new software applications. Beyond developing new applications, developers must define and generate accurate test data and test cases. Organizations tend to use legacy GAPs as long as possible in business operations, primarily to realize the return on investment for the legacy GAPs. However, developers find extracting data from GAPs difficult, because the vast majority of GAPs are closed and monolithic. In other words, most GAPs do not expose programming interfaces or data in known formats. Thus, while developers find the use of GAPs to extract test data and test cases desirable, often the original implementation of a GAP makes the extraction impossible.
In contrast to GAPs, developers design web services as software components that flexibly exchange information over networks, including the Internet. Consequently, business industry demand for applications that easily and inexpensively exchange information has partly caused widespread acceptance of web services. Employing web services, unlike GAPs, enables organizations to quickly build integrated systems by composing (i.e., configuring) the web services for information exchange. Organizations easily migrate and/or model functionality from existing web services to other web services. However, migrating or modelling functionality in GAPs to generate test data and test cases for web services provide a considerable technical challenge for organizations and developers.
Organizations have invested heavily in legacy GAPs and developers find it difficult and time consuming to analyze the source code of GAPs to extract data and test cases, because of brittle legacy architectures, poor documentation, significant programming effort, and subsequently, the large cost of such projects. Organizations often do not have access to the source code necessary to analyze and develop data extraction and test cases from GAPs, in particular regarding third-party provided GAPs. Given the complexity of GAPs and the cost to migrate and model GAPs to create new web services, a fundamental problem exists of how to extract test data and test cases from GAPs to test web services, and generate production data from GAPs, efficiently and non-invasively.
A need has long existed for a system and method to economically and efficiently extract test cases and production data from GAPs for web services.